Extension Points

This page explains the various extensions available to extend the digital banking apps. It is assumed that you are already familiar with the Digital Banking reference architecture (MVC). See also How to Extend the Existing Features for more information.

Overview

The major requirements of Digital Banking apps are around Upgrades and Extensions. Using the reference architecture, you can achieve these requirements efficiently. The framework provides extensions over the existing layers which can extend any existing feature( before/after) or bring in a new feature. The salient features are:

• It is a layered architecture, which has a common model layer, a business layer with many commands, and a presentation layer. The loose coupling between the layers can help this process.

• It provides the following layer extensions:

  • Presentation layer
  • Business layer
  • View Layer layer

Presentation Extensions

• The framework provides extension mechanisms such as the Presentation Extension Class.
• The presentation extension can extend the existing Presentation Controller Classes methods. This can involve overriding a business call which is made by the presentation controller or it can be by changing the view logic which is defined in the presentation controller.
• 

Based on the diagram, the presentation layer extensions can do the following:

• The presentation controller has a Presentation Logic 1 which calls Command 1. In the presentation extensions, we can override the Presentation Logic 1 function and we can call some other different business logic. This means that by this extension mechanism, the presentation which calls the Command 1, now I can make the Presentation Logic 1 to call any other command.
• The presentation controller also has a logic, Presentation Logic 3 which is a viewModel logic. The viewModel logic is an object that the presentation sends to the view, so whatever the presentation layer sends information to the view, you can send additional information to the view if you override the Presentation Logic 3.
• By this second implementation, you can even change the view that you are displaying. This kind of presentation extensibility can seamlessly change the view by overriding the method in the presentation controller.

How is the presentation controller extended

• The module config specifies the presentation extension classes.

• The Presentation Controller config mentions the presentation layer configurations. It mentions the base Presentation Class and the Presentation Extension classes. This is where you specify the presentation extension class.

Business Extensions

• The business extensions implies the extension of  business logic that you write in the command handlers and the business delegator.

• Business layer can implement either of the design patterns:

  • Command Pattern

  • Delegator Pattern

Business Extensions using Command Pattern

• The app architecture also provides a method to extend the existing business layer by extending the Command Handler class which contains the business logic. The extension is possible on the business logic.
• Apart from changing the existing logic a bit, there is also a provision for adding some logic before and after the existing business logic.
• The way to enable the command handler extensions is by mentioning the CommandHandlerExtension class in the module config:

• The command handler extension methods, AddBefore and AddAfter basically helps in this extensibility.

• The command handler extension class is mentioned in the module config as shown above. In the above example, the AccountModule_GetAll_Handler, this class implementation is as follows:
• This is the base command handler and it will have the business logic inside the execute method. With the help of the command handler extension, you can either override the whole business logic, or you can add some logic before the execute method like a pre processor method, and you can add some logic after the execute method like post processor. This pre processor method called addBefore, can involve a gateway check logical implementation of the context that enters into the command handler, and the post processor method, addAfter can involve the data processing or checking after making the execute call.
• The following is the command handler extension:

• The addBefore API works as a preprocessor wherein it can abort the business implementation by returning a boolean value. Validation of the information can be done here, and then if something is wrong here, we can return false and the sendResponse API gets invoked automatically. The sendResponse API of command handler class returns a null response with status as STATUS_ABORT (constant).

Business Extensions using Delegator Pattern

• The app architecture provides extensibility over the business delegate pattern too. Business Delegate is a class wherein all the business calls get delegated to, from the presentation layer. Having extensions support at business layer can make necessary business extensions.

• When the business layer uses the delegator pattern, the business logic can be extended using the BusinessExtensions defined in the module config. We mention the business extensions as follows:

• The Transaction Module uses the Business Controller as a delegator pattern. Unlike the Business Controller as a Command Pattern which has Command Handler/Command Handler Extensions key-values, the Business Controller as a delegator has Business Controller Class and Business Extensions key-value mentioned in the module config.
• In the Business Extensions, we mention our JS file list
• In the Business Extension classes, we can have the methods which can override the existing business implementations and new implementations can be defined.
• Once a method got overridden, the business controller instance will not contain the parent method. For using this parent method in the child method super method can be used. Refer the Business Delegator API documentation.
• The business delegator class has methods. These methods are business implementations:

• These class methods that we see, get transactions, operation1, all of there methods are the business implementations. In our business extensions, we can override these methods and implement new business logic.

This is the businessExtension1

• In this extension, we override the existing business implementation(operation1) and also creating a new business implementation(operation2).
• Once operation1 is overridden, the base BusinessController method is no more available to call. So, to call the overridden method, we can use the super method.

This is businessExtension2

• In this extension, we have overridden the base BusinessController method getTransactions. In this new method, getTransactions of businessExtension2, we just add one line and then again call the base method using the super method.
• Similarly, in the method operation2 in businessExtension2, we override the operation2 method of businessExtension1. From operation2 we call the overridden method which is defined in the first level of extension(businessExtension1) using the super method.
• The super takes inputs as the,
  • method name
  • array/list of arguments to the method

View Extensions

• Whenever the presentation layer view model logic gets changed, there is a need to change the view controller implementation. This view controller functionality can be overridden by the same extension mechanism just like the presentation.

• In the module config, if we see the forms section, the Controller is mentioned. This is the base controller and this has functions which are all view related functions. So, when the presentation layer sends additional information to view level, the existing method of view controller cannot handle it, but you need to override this view controller method and then implement this method to handle this new logic. This way, you can extend the view layer. The Controller Extensions key must be updated with a JS require type file name and this file becomes an extension to the form controller.

Dos and Dont's

• All modules have the following:
  • Business Controller/Command Handler at module level
  • Presentation Controller at module level
  • View Controller at form level
• All the business logic involving the models and any service calls should be done in the layer.
• Presentation logic can only process the data and send this data to any form.
• The UI changes that the application has in the view layer are to be handled totally in view controller.
• If one layer wants to talk to other layer, the instance of the layers are not to be passed. For example, if the view layer wants to send some data back to the presentation layer, then the instance of view should not be sent back. Instead, the data should be sent.
• Any callbacks, either the callbacks in presentation layer or the business layer, these callbacks are not to be anonymous and also these callbacks should be coded where they should be.
• MVC only speaks with objects.
• There should always be a unique Quantum Fabric object in the app architecture (MVC) application, though Quantum Fabric supports same object names across multiple Object Services.